优化你的 HTTPS，你需要这么做

Linux云计算网络 2021-12-21

阅读本文大概需要 10 分钟。

来源：公众号“运维实谈”

HTTP/2

HTTP 2.0即超文本传输协议 2.0，是下一代HTTP协议。是由互联网工程任务组（IETF）的Hypertext Transfer Protocol Bis (httpbis)工作小组进行开发。是自1999年http1.1发布后的首个更新，HTTP/2 协议是从 SPDY 演变而来，SPDY 已经完成了使命并很快就会退出历史舞台（例如 Chrome 在「2016 年初结束对 SPDY 的支持」；Nginx在版本1.9.5+，Apache在版本2.4.16+都已经全面支持HTTP/2。

首先看看HTTP/2的一些新特性：

二进制分帧
首部压缩
流量控制
多路复用
请求优先级
服务器推送

二进制分帧

二进制分帧层，是HTTP2.0性能增强的核心。

HTTP 1.x在应用层以纯文本的形式进行通信，HTTP2.0在不改变HTTP1.x的语义、方法、状态码、URL以及首部字段的情况下，为了突破原有性能限制，在应用层(HTTP)和传输层(TCP)之间增加了一个二进制分帧层。HTTP2.0将所有的传输信息分割为更小的消息和帧，并对它们采用二进制格式编码，如下图所示。

这里引入一个新的通信单位：帧。

帧是HTTP 2.0通信的最小单位，包括帧首部、流标识符、优先值和帧净荷等。

其中，帧类型可以分为：

DATA：用于传输HTTP消息体
HEADERS：用于传输首部字段
SETTINGS：用于约定客户端和服务端的配置数据。比如设置初识的双向流量控制窗口大小
WINDOW_UPDATE：用于调整个别流或个别连接的流量
PRIORITY：用于指定或重新指定引用资源的优先级
RST_STREAM：用于通知流的非正常终止
PUSH_ PROMISE：服务端推送许可
PING：用于计算往返时间，执行“ 活性” 检活
GOAWAY：用于通知对端停止在当前连接中创建流

标志位，用于不同的帧类型定义特定的消息标志。比如DATA帧就可以使用End Stream: true表示该条消息通信完毕；流标识位表示帧所属的流ID；优先值用于HEADERS帧，表示请求优先级；R表示保留。

下面是抓包的一个HEADERS帧：

另外一个两个要说一下的概念：消息和流。

消息是指逻辑上的HTTP消息(请求/响应)，一系列数据帧组成一个完整的消息，比如一系列DATA帧和一个HEADERS帧组成了请求消息。

流是链接中的一个虚拟信道，可以承载双向消息传输，每个流有唯一证书标识符，为了防止两端流ID冲突，客户端发起的流具有奇数ID，服务端发起的流具有偶数ID。

所有HTTP 2.0通信都在一个TCP链接上完成，这个链接可以承载任意数量的双向数据流Stream。相应地，每个数据流以消息的形式发送，而消息由一个或多个帧组成，这些帧可以乱序发送，然后根据每个帧首部的流标识符重新组装。

二进制分帧主要是为HTTP2.0其他特性提供基础。它能把一个数据划分封装为更小更便捷的数据。首先是在单链多资源方式中，减少服务端的链接压力，内存占用更少，链接吞吐量更大；另一方面，由于TCP链接的减少而使网络拥塞状态得以改善，同时慢启动时间减少，使拥塞和丢包恢复的速度更快。

首部压缩

HTTP1.x每次通信(请求或响应)都会携带首部信息用于描述资源属性。而HTTP2.0在客户端和服务端之间使用首部表来跟踪和存储之前发送的键值对，首部表在连接过程中始终存在，新增的键值对会更新到表尾，因此不需要每次通信都携带首部，请求与响应首部的定义在HTTP2.0中基本没有变。

另外HTTP2.0使用了首部压缩技术，压缩算法采用HPACK，让报头更紧凑、更快速传输，有利于移动网络环境。需要注意的是，HTTP2.0的首部压缩，与我们常用的gzip等报文内容压缩不冲突。

流量控制

HTTP/2.0 “流”的流量控制的目标是：在不改变协议的情况下允许使用多种流量控制算法

流量控制是特定于一个连接的。每种类型的流量控制都是在单独的一跳的两个端点之间的，并不是在整个端到端的路径上的。（这里的一跳指的是HTTP连接的一跳，而不是IP路由的一跳）
流量控制是基于WINDOW_UPDATE帧的。接收方公布自己打算在每个流以及整个连接上分别接收多少字节。这是一个以信用为基础的方案。
流量控制是有方向的，由接收者全面控制。接收方可以为每个流和整个连接设置任意的窗口大小。发送方必须尊重接收方设置的流量控制限制。客户方、服务端和中间代理作为接收方时都独立地公布各自的流量控制窗口，作为发送方时都遵守对端的流量控制设置。
无论是新流还是整个连接，流量控制窗口的初始值是65535字节。
帧的类型决定了流量控制是否适用于帧。目前，只有DATA帧服从流量控制，所有其它类型的帧并不消耗流量控制窗口的空间。这保证了重要的控制帧不会被流量控制阻塞。
流量控制不能被禁用。
HTTP/2只定义了WINDOW_UPDATE帧的格式和语义，并没有规定接收方如何决定何时发送帧、发送什么样的值，也没有规定发送方如何选择发送包。具体实现可以选择任何满足需求的算法。

多路复用

在HTTP1.1中，浏览器客户端在同一时间，针对同一域名下的请求有一定数量的限制。超过限制数目的请求会被阻塞，而HTTP2.0中的多路复用优化了这一性能。

基于二进制分帧层，HTTP2.0可以在共享TCP连接的基础上，同时发送请求和响应。HTTP消息被分解为独立的帧，而不破坏消息本身的语义，交错发送出去，最后在另一端根据流ID和首部将他们重新组合。对比看一下HTTP1.x和HTTP2.0，这里不考虑HTTP1.x的pipeline机制。

HTTP2.0成功解决了HTTP1.x的队首阻塞问题(TCP层的阻塞仍无法解决)，同时，也不需要通过pipeline机制多条TCP连接来实现并行请求与响应。减少了TCP连接数对服务器性能有很大提升，同时也消除不必要的延迟，从而减少页面加载的时间。

请求优先级

把HTTP消息分为很多独立帧之后，就可以通过优化这些帧的交错和传输顺序进一步优化性能。

每个流都可以带有一个31bit的优先值：0表示最高优先级；2的31次方-1表示最低优先级。

客户端明确指定优先级，服务端可以根据这个优先级作为交互数据的依据，比如客户端优先设置为.css>.js>.jpg。服务端按此顺序返回结果更加有利于高效利用底层连接，提高用户体验。然而，在使用请求优先级时应注意服务端是否支持请求优先级，是否会引起队首阻塞问题，比如高优先级的慢响应请求会阻塞其他资源的交互。

服务器推送

HTTP2.0增加了服务端推送功能，服务端可以根据客户端的请求，提前返回多个响应，推送额外的资源给客户端

如下图，客户端请求stream 1(/page.html)。服务器在返回stream 1的消息的同时推送了stream 2(/script.js)和stream4(/style.css)

PUSH_PROMISE帧是服务端向客户端有意推送资源的信号。
PUSH_PROMISE帧中只包含预推送资源的首部。如果客户端对PUSH_PROMISE帧没有意见，服务端在PUSH_PROMISE帧后发送响应的DATA帧。如果客户端已经缓存了该资源，不需要推送，可以拒绝PUSH_PROMISE帧。
PUSH-PROMISE必须遵循请求-响应原则，只能借着对请求的响应推送资源。
PUSH_PROMISE帧必须在返回响应之前发送，以免客户端出现竞态条件（竞态条件是指在多线程的情况下不同的执行顺序会导致计算机执行出不同的结果正确性不同）
HTTP2.0连接后，客户端与服务端交换SETTINGS帧，借此限定双向并发的最大数量。因此，客户端可以限定推送流的数量，或者通过把这个只设置为0来完全禁止服务器推送。
所有推送的资源都必须遵守同源策略。换句话说，服务器不能随便将第三方资源推送给客户端，而必须是经过双方的确认才行。

HTTP/2现在已经获得绝大多数浏览器的支持，不过在使用过程中HTTP/2需要使用1.0.1e之后的openssl版本，通过nginx -V，可以查看nginx的openssl版本，如果版本低，重新编译nginx即可。

那么在nginx中如何配置支持HTTP/2？很简单，只需要在server中的listen部分添加http2即可。

怎么测试http2是否已开启，方法很多，这里介绍三种方法：

1、浏览器开发者工具

2、Chrome扩展HTTP/2 and SPDY indicator

3、命令行客户端nghttp

另外HTTP/2的服务器推送，需要nginx配置才能有效利用。

通过http2_push指令配置

这种情况下，demo.html需要用到的资源style.css、image1.jpg和image2.jpg被推送到客户端。资源少的情况下，我们可以这么使用，但是资源多的情况下这种方式就不太现实。

自动将资源推送给客户端

nginx支持拦截link预加载头的约定，推送这写头中标识的资源，需要在配置中启动预加载，配置http2_push_preload on

这里也有一个问题，一般的静态资源，我们都会设置缓存有效期。当客户端资源在缓存有效期内的时候，我们强制推送静态资源，只会增加服务器带宽的压力，所以我们需要指定客户端是否需要这些资源，并且不太可能已经缓存过，可能的方法，就是客户端在首次访问时服务端推送，并在随后的访问请求中包含cookie，服务端通过cookie去判断是否进行推送，就是有选择的向客户端推送资源，配置方法如下：

测试如下：

TLS 1.3

TLS(Transport Layer Security Protocol，传输层安全协议)主要目的是提供隐私和数据亮哥通信应用之间的完整性。该协议由两层组成：TLS记录协议(TLS Record)和TLS握手协议(TLS Handshake)。

TLS协议经过很多次版本的更新，目前低版本的TLS，如SSL 3.0/TLS 1.0等，存在许多严重漏洞，目前受到主流支持的TLS协议版本是1.1和1.2，但也都已经落后于时代的需求。在2018年8月份，IETF终于宣布TLS 1.3规范正式发布了，标准规范定义在rfc8446。

相较于之前的版本TLS优化内容有：

相比过去的的版本，引入了新的密钥协商机制 — PSK
支持 0-RTT 数据传输，在建立连接时节省了往返时间
废弃了 3DES、RC4、AES-CBC 等加密组件，废弃了 SHA1、MD5 等哈希算法
ServerHello 之后的所有握手消息采取了加密操作，可见明文大大减少
不再允许对加密报文进行压缩、不再允许双方发起重协商
DSA 证书不再允许在 TLS 1.3 中使用

在https中，每个连接的TLS的握手是很消耗资源及时间的，所以TLS 1.3的优化，比之前的版本建立连接的时间少了一个RTT，同等情况下，节省了很多时间，提高了响应速度。

TLS 1.3需要openssl 1.1.1支持，在nginx上，需要nginx 1.13+支持。

在编译nginx的时候，需要添加编译参数--with-openssl-opt=enable-tls1_3来开启TLS 1.3支持，并在配置中ssl_protocols中添加TLSv1.3，对应的TLS1.3引入了新的算法，所以ssl_ciphers也需要添加新算法

默认情况下nginx因为安全原因，没有开启TLS 1.3的 0-RTT，可以通过指令ssl_early_data on来开启。

ECC

ECC(Elliptic curve cryptography，椭圆曲线密码学)，一种建立公开密钥的算法，基于椭圆曲线数学。

内置ECDSA公钥的证书一般称为ECC证书，内置RSA公钥的证书一般称为RSA证书。

ECC算法的数学理论非常深奥和复杂，在工程应用中比较难于实现，但它的单位安全强度相对较高，它的破译或求解难度基本上是指数级的，黑客很难用通常使用的暴力破解的方法来破解。RSA算法的特点之一是数学原理相对简单，在工程应用中比较易于实现，但它的单位安全强度相对较低。因此，ECC算法的可以用较少的计算能力提供比RSA加密算法更高的安全强度，有效地解决了“提高安全强度必须增加密钥长度”的工程实现问题。

与RSA算法相比，ECC算法拥有一下优势：

更适合于移动互联网：ECC加密算法的密钥长度很短(256位)，意味着占用更少的存储空间，更低的CPU开销和占用更少的带宽。随着越来越多的用户使用移动设备来完成各种网上活动，ECC加密算法为移动互联网安全提供更好的客户体验。
更好的安全性：ECC加密算法提供更强的保护，比目前的其他加密算法能更好的防止攻击，使你的网站和基础设施比用传统的加密方法更安全，为移动互联网安全提供更好的保障。
更好的性能：ECC加密算法需要较短的密钥长度来提供更好的安全，例如，256位的ECC密钥加密强度等同于3072位RSA密钥的水平(目前普通使用的RSA密钥长度是2048位)。其结果是你以更低的计算能力代价得到了更高的安全性。经国外有关权威机构测试，在Apache和IIS服务器采用ECC算法，Web服务器响应时间比RSA快十几倍。
更大的IT投资回报：ECC可帮助保护您的基础设施的投资，提供更高的安全性，并快速处理爆炸增长的移动设备的安全连接。ECC的密钥长度增加速度比其他的加密方法都慢(一般按128位增长，而 RSA则是倍数增长，如：1024 –2048--4096)，将延长您现有硬件的使用寿命，让您的投资带来更大的回报。

不过使用ECC证书有两个问题需要注意：

1、不是所有类型证书都支持ECC，一般需要商业证书的增强版本中才支持

2、一些旧的设备或浏览器不支持ECC，可能需要ECC+RSA双证书的模式来使用

Brotli

Brotli是Google于2015年9月推出的无损压缩算法，Brotli通过变种的LZ77算法、Huffman编码以及二阶文本建模等方式进行数据压缩，与其他压缩算法相比，它有者更高的压缩效率。

更具Google发布的报告指出，Brotli有一下特点：